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PAYMENT SYSTEM FOR SOFTWARE PROGRAM USE_ 
DESCRIPTION 

5 Field of the invention 

The purpose of the present invention is to provide 
a payment system for software program use. This 
software may be of any type and may, for example, be 
recorded on media such as CD-ROM (Compact Disc Read- 
10 Only Memory) or DVD-ROM (Digital Versatile Disc Read- 
only Memory) , or else be downloaded. 

It may relate to scientific calculations, games 
and computer-assisted techniques as well as word- 
processing, etc. 

15 

Background of the invention 

CD-ROMs are currently the main method of software 
program distribution, and will very shortly be replaced 
by the DVD-ROM. For software editors, illicit copying 

20 of their software is becoming an increasingly serious 
problem. Although for some time the CD-ROM format 
prevented the copying of software onto blank disks, 
user-recordable disks and CD burners are now accessible 
in the mass consumer market; the same phenomenon will 

25 undoubtedly also not take long to arrive with DVD 
technology. 

Another potential method of software distribution, 
although less commonly used for performance reasons, is 
downloading. This method is not suitable for games 
30 requiring large numbers of images or three-dimensional 
scenes. On the other hand, it can be highly suitable in 
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other cases, such as many software programs (program 
compilers, editors etc.). In general, these software 
programs are free, as, because of their small size 
(enabling them to be downloaded), they can be very 
easily copied from one computer to another. 

Furthermore, it is clear that the high purchase 
price of a software program often acts as a deterrent 
to users. The cost of the CD-ROM disk and its burning 
is a very small factor in that price. In reality, the 
high purchase price of current CDs/DVD-ROMs mainly 
corresponds to payment for the software editors and 
games distributors. 

These observations lead us to the conclusion that 
there is a need for per-use, per-period or per-session 
payment for software on CD/DVD-ROM media or downloaded 
software. Software editors would then receive payment 
from a much wider customer base, based on the use the 
customer makes of that software. Globally, such a 
process should rather increase sales in the software 
industry. In addition, there would no longer be any 
reason to copy the software medium, as it would in any 
event be necessary to pay to use the software. 

However, there are currently no reliable and sure 
means of ensuring payment for software program use. The 
aim of the present invention is to remedy precisely 
that lack. 
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Description of the invention 

A payment system for software program use must 
fulfil at least three functions: 

• controlling the software's use, each time that 
software is run, periodically or whenever a 
particular event occurs in the software (such as 
changing "worlds" in a game, changing to the second 
act in a play or film, etc.); the software must then 
request payment; 

• recording the number of times the software is used, 
to impose payment by the user; if the user accepts 
the payment request, that request must be recorded 
securely so that the user is obliged to pay later. 
Security features must prevent the user from erasing 
his/her debts, and it must be possible to total small 
amounts within the deferred payment so that the user 
can periodically be presented with an overall bill 
(each month, for example) , both for practical reasons 
but also because of the cost of recovering such small 
amounts ; 

• periodically transferring to the software editor the 
amount owed. 

These functions must be performed while catering 
for certain constraints: 

• the CD-ROMs may be foreign: a software payment system 
must therefore include cross-border characteristics 
and so mechanisms able to be deployed 
internationally, as well as being internationally 
recognised by the standardisation committees; 

• there must be a standard interface between software 
and the means of payment so that a software developer 
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does not have to program the payment logic 
corresponding to use of this software 
himself /herself ; 

• the system that records the number of times the 
5 software is used must be able to trigger 

international payments to pay software editors in any 
country worldwide; 

• it must be possible to accumulate user payments and 
transfers to the software editors; as already said, 

10 this is aimed at simplifying payments but is also in 

order to reduce banking charges; notably, in the case 
of transactions with foreign countries it would be 
inefficient (or even financially detrimental), from 
the expense point of view, to make too many transfers 

15 of small sums. 

The present invention meets all these requirements 
and caters for all these constraints. To this end, the 
system in the invention is made up of a payment module 
20 and a means of message and payment processing. 
Furthermore, the software whose use is to be controlled 
includes a software interface. The functions of these 
means are as follows: 

• the software interface is capable of composing a 
25 first message offering use of the software; this 

first message notably contains the software editor's 
identity, the offer parameters and the editor' s 
digital signature for at least part of the software 
offered, and is sent to the payment module; 
30 • the payment module is capable of receiving this first 
message, displaying it, receiving the software user's 
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acceptance should he/she so accept, and, if so, 
composing a second message requesting payment, 
notably containing the identity of the user and of 
the software editor together with proof that the user 
5 accepts the offer; this module is capable of sending 

this second message to the means of processing; 

• the means of message and payment processing are able 
to receive the second message, check the proof it 
contains, record the payment request containing at 

10 least the user's identity, the software editor's 

identity and the amount to be paid, and credit the 
editor with the said amount; these means are also 
able to compose a third message, which is a payment 
settlement message. This third message notably 

15 contains the identity of the means of payment and a 

digital signature for the offer, and is addressed to 
the payment module; 

• the payment module is also able to resend this third 
message to the software interface; 

20 • the software interface is also able to check the 
means of processing's signature against the offer 
parameters contained in the first message and, if 
they agree, authorise the software's use. 

In a first variation, the means of message and 
25 payment processing are made up of a remote payment 
server linked to the payment module via a 
telecommunications network; this payment server 
receives and processes the second message and then 
composes and sends the third message. This payment 
30 server totals up the elemental credits in order to 
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periodically transfer to the software editors the 
amounts owing to them. 

In a second variation, the means of message and 
payment processing include secure means containing at 

5 least the user's identity; these means are additionally 
able to receive the second message, check the proof it 
contains, record the payment request and compose the 
third, payment settlement, message, and also include a 
remote payment server able to credit the software 

10 editor. 

In this variation, the secure means can include a 
smart card reader with a smart card containing the 
user' s identity; this card is able to receive the 
second message, check the proof it contains, record the 

15 payment request and compose the third, payment 
settlement, message. 

The server is regularly updated with all requests 
recorded in the card, which correspond to the use of 
software programs, via a telecommunications network. 

20 The card may be either of prepay (in the form of 

an electronic wallet, for example) or post-pay type. 

Both prepay and post-pay cards are able to build 
up a file containing the settled requests and 
corresponding amounts; the payment settlement message 

25 is only sent with its digital signature once this file 
has been updated. 

The purpose of the present invention is also to 
provide a payment module for a payment system for 
software program use, the characteristics of which are 

30 that it is made up of the following: 



SP 16448. C/RS 



7 



• the means of processing a first message, notably 
containing a software editor's identity, 
software use offer parameters and a digital 
signature for at least part of that software use 
offer; 

• the means of sending this message to a user; 

• the means of receiving an acceptance from said 
software program user; 

• the means of composing a second message 
requesting payment, notably containing the 
user' s identity and editor' s identity together 
with proof that the user accepts the offer; 

• the means of receiving and processing a third 
message containing a digital signature 
constituting proof of payment. 

The purpose of the present invention is also to 
provide the means of processing messages and payments 
for a payment system for software program use, the 
characteristics of which are that it is made up of the 
following : 

• the means of receiving a payment request message 
from a payment module, in which that message 
notably contains a user's identity and a 
software editor' s identity together with proof 
that the user accepts the software use offer 
made to him/her; 

• the means of checking that proof; 

• the means of recording the payment request with 
at least the user' s identity and the software 
editor's identity, the amount to be paid and 
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means able to credit the software editor with 
said amount; 

• the means of also composing a payment settlement 
message, notably containing the identity of the 

5 means of payment and a digital signature 

constituting proof of payment; 

• the means of sending this message to a payment 
module. 

10 Brief description of the drawings 

- Figure 1 shows a system complying with the first 
variation of the invention; 

- Figure 2 shows a certification tree with a chain 
of certificates; 

15 - Figure 3 shows a system complying with the 

second variation of the invention. 

Detailed description of the preferred embodiment 

Figure 1 shows a PC-compatible personal computer 
20 supposed to contain a software program (L) whose use we 
wish to control. This software program is coupled with 
a software interface (IL) , hereinafter called 
"MERCHANT", that communicates with the payment system 
itself. It also shows a payment module (W) , hereinafter 
25 called "WALLET". The figure also shows a remote payment 
server (SP) , linked to the WALLET module by a 
transmission line (not shown) . The software editor is 
marked E. 

In the variation shown in Figure 1, when software 
30 program L has decided to request a new payment, an 
offer message, labelled "1", is sent by the MERCHANT 
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interface to the WALLET module. This offer message can 
contain the following: 

• software editor' s identity; 

• offer description, in text that can be understood by 
5 the user, explaining what he/she will obtain in 

return for making payment (e.g. "30 minutes' 
additional use" or "Scene 3: length 25 minutes"); 

• price (amount, currency, etc.); 

• PC's internal clock date and time; 
10 • an internal random number; 

• a signature belonging to the offer's software editor, 
in the form Sg (offer^, price) where offers means 
"summarised offer data". 

The WALLET module receiving this message will ask the 
15 user (U) if he/she agrees to accept that offer. For 
example, a window is displayed on the screen, showing 
the offer's description, date and time, the payment 
amount and currency, and the same price converted into 
French Francs. This display is represented by arrow la 
20 in Figure 1 . 

If user U agrees to the offer, he/she clicks (for 
example) an "Agree" button (this reply is represented 
by arrow lb in Figure 1) . The WALLET module then sends 
message 2, "payment request", to server SP. This 
25 message can contain the following: 

• a summary of offer^, the price, date and time, random 
number, and signature Sg (offer^, price) ; 

• the identity of user U and the identity of software 
editor E; 
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• proof that the customer agrees to buy that offer. The 
type of proof can depend on how the invention is 
implemented; it may consist in a password sent to 
payment server SP, a secret code contained in a smart 

5 card that itself provides server SP with encrypted 

proof, signature, etc. 

The fact that a summary of the offer ("offers") is 
sent rather than the complete offer means that the 
customer need not reveal to server SP what he/she has 
10 selected, without preventing checking by server SP. 

The payment server SP that receives the payment 
request (marked 2 in Figure 1) then performs the 
following operations: 

• checking the proof given by the customer; 

15 • converting the amount into French Francs if 
necessary; 

• checking the user's consumption; for example, server 
SP checks that the user's total consumption since the 
beginning of the period is less than the authorised 

20 amount allocated to that user (post-pay customers) , 

or else checks that the total consumption is less 
than the provision built up by the user for that use 
(prepay customers) ; 

• recording the payment request so that it can later 
25 perform the payment operations; this record contains 

at least the following information: 

- user' s identity 

- software editor' s identity 

- price 

30 - date and time, summary of offer^ etc. 
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• it composes message 3, the payment settlement 
message, which will prove to the software program and 
its "MERCHANT" interface that payment has indeed been 
made; in order to provide verifiable proof, this 
5 payment settlement message will contain the following 

information : 

- server SP' s identity 

- signature Ssp (offer^, price, random number, 
date-time) from the payment server 

10 The WALLET module simply sends the message it 

receives to the MERCHANT interface. 

The MERCHANT interface checks the payment 

settlement message's signature Sgp (offer^, price, 

random number, date-time) against the parameters of the 
15 offer previously sent. If these agree, software L can 

continue to run. 

Periodically, every month for example, server SP 

calculates each user' s total consumption and triggers 

(for post-pay customers) actual payment of the sums 
20 owing by means of a customer-held bank or credit card, 

whose card number must be known in advance, or by 

direct debit from the customer's account. 

Prepay users pay by choosing to top up their 

balance via an intermediary. 
25 The total calculated per software editor means 

that the amount owed to each software editor can 

likewise be calculated. 

The dotted lines in the drawing in Figure 1 

correspond to the financial flow from server SP to the 
30 software editor. 
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To set up the different signatures mentioned 
above, a system using a public key with a certification 
tree can be used. This is in fact one of the rare 
solutions allowing simple, safe, open and 
5 internationally recognised systems to be designed. 

The principles of this technique are well known. 
Its implementation is shown in the diagram in Figure 2. 
An authority (A) defines the certification tree's 
"root", containing the system's different participants: 
10 - the software editors using this means of payment 

- the payment servers (SP) 

- the intermediaries; in the example shown in 
Figure 2, these could be a country's software 
editors association (SYND) and a national 

15 regulatory authority governing that country' s 

Internet servers (SINT) . 

In this way, when a software program produced by a 
certain software editor is used by a user corresponding 
to a given SP server, one or more of the certificates 
20 attached to messages 1 and 3 are used to check the 
signatures . 

In offer messages (message 1), the software editor 
(E) can send server SP a message containing the summary 
of offers, the price, date-time, random number, 
25 signature S2 (offer^, price) , the E certificate sent by 
SYND, and the SYND certificate sent by A. 

Server SP, which knows A' s public key, checks the 
SYND certificate sent by A, using A' s public key. It 
therefore obtains the SYND public key securely and 
30 checks the E certificate sent by SYND, using the SYND 
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public key. It therefore obtains the E public key 
securely and can finally check signature Sg. 

The variation described above can be classified as 
5 an "online 7 ' solution, as the user must connect, using 
the Internet for example, to server SP at each payment 
request. This version is only acceptable for infrequent 
payments (for example, to receive a 2-hour film on DVD- 
ROM) . 

10 The present invention envisages another variation 

better suited to repeat payments. This variation is 
described in Figure 3. It assumes the presence of a 
card reader (LC) and a card (C) . As the card is a 
secure medium, it replaces server SP in the case of 
15 messages 2 and 3, which then pass between module W and 
card reader LC. This variation can be classified as an 
"off line 7 ' solution, unlike the former variation. 
Software editor E is still paid by payment server SP, 
which periodically receives the information recorded in 
20 the card (line PP) . 

Card C may be of two types: 
• Prepay cards ("electronic wallet" type, for example) : 
the balance is reduced each time a payment request 
message is processed. There is therefore no risk of 
25 unpaid debts, as the cards must have been credited 

before being emptied; however, the number of times 
the software has been used must be recorded in order 
to be able to pay the software editors according to 
use made of their software. This may be done when the 
30 cards are topped up again, for example; 
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• Post-pay cards: there is a risk that the software use 
recorded in the card may never reach the intermediary 
and so the customer is never debited, with the result 
that the editors of the software used are never 
credited. The way of handling this problem consists 
in restricting payments to a certain limit and/or 
making users pay a larger deposit than that limit, 
dissuading the users from having their card 
"disappear" . 

In terms of the exact mechanisms used, the second 
variation is very similar to the first, except that 
server SP is replaced by card C. This card must 
therefore contain a file recording all use and that, as 
is the case with server SP, will contain the 
transaction records, themselves containing at least the 
following information: 

- user' s identity 

- software editor's identity 

- price. 

If we allow a little security to be lost in order 
to avoid the additional cost of the card reader, the 
card can be replaced by an integrated means of 
recording within the PC. 

To prevent the payment requests file from being 
too easily changed or erased, techniques consisting in 
fragmenting/scattering its information over the entire 
disk must be used; their complexity will offer a 
barrier, admittedly less strong than the physical 
security offered by smart cards, but sufficient in many 
cases . 
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CLAIMS 

1. A payment system for use of a software program 
(L) stored on a medium, whereby said software contains 
5 an interface (IL) and said system is made up of a 
payment module (W) together with the means of message 
and payment processing (SP) , and whereby the functions 
of these means are as follows: 

the software interface (IL) is able to compose a 

10 first message (1) offering use of the software; said 
first message (1) notably contains the identity of the 
software editor (E) , offer parameters and the editor's 
digital signature for at least part of the software 
offered, and is sent to the payment module (W) ; 

15 the payment module (W) is able to receive said 

first message (1), display it (la), receive the 
acceptance (lb) of the software user (U) should he/she 
so accept, and, if so, compose a second message (2) 
requesting payment, notably containing the identity of 

20 the user (U) and of the software editor (E) together 
with proof that the user (U) accepts the offer; said 
module (W) is also able to send said second message (2) 
to the means of message and payment processing (SP) ; 

the means of message and payment processing (SP) 

25 are able to receive the second message (2), check the 
proof it contains, record the payment request with at 
least the identity of the user (U) and of the software 
editor (E) and the amount to be paid, and credit the 
editor (E) with said amount; said means are also able 

30 to compose a third message (3) , which is a payment 
settlement message. This third message (3) notably 
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contains the identity of the means of processing and a 
digital signature constituting proof of payment, and is 
addressed to the payment module (W) ; 

the payment module (W) is additionally able to 
5 resend said third message (3) to the software interface 
(IL) ; 

the software interface (IL) is additionally able 
to check the means of processing's signature against 
the offer parameters contained in the first message 
10 and, if they agree, authorise use of the software 
program (L) . 

2. A system in accordance with claim 1, whereby 
the digital signature by the editor of at least part of 

15 the offer and the digital signature constituting proof 
of payment are both public key signatures with 
certification trees, whereby an authority (A) defines 
the root of the certification tree containing the 
system's different participants, notably the software 

20 editors (E) and payment servers (SP) , and whereby one 
or more certificates are attached to the first and 
third messages (1) (3) for signature checking. 

3. A system in accordance with claim 1, whereby 
25 the means of message and payment processing are made up 

of a remote payment server (SP) linked to the payment 
module (W) by a telecommunications network, and whereby 
said server (SP) receives and processes the second 
message (2) and composes and sends the third message 
30 (3); said payment server calculates the total 
consumption of each user for all of the software 
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editors in order to impose payment by said user and 
causes the sums owing to each software editor to be 
transferred by all of the users. 

5 4. A system in accordance with claim 1, whereby 

the means of message and payment, processing includes 
secure means (LC, C) containing at least the identity 
of the user (U) ; said means are additionally able to 
receive the second message (2), check the proof it 
10 contains, record the payment request and compose the 
third, payment settlement, message (3) , and also 
include a remote payment server (SP) able to credit the 
software editor (E) . 

15 5. A system in accordance with claim 4, whereby 

the secure means include a smart card reader (LC) with 
a smart card (C) containing the user's identity, and 
whereby said reader and card are able to receive the 
second message (2) , check the proof it contains, record 

20 the payment request and compose the third, payment 
settlement, message (3) with the proof of payment. 

6. A system in accordance with claim 5, whereby 
the card (C) is of the prepay type and contains a 

25 balance and whereby the card is able to debit said 
balance with the request amount at each payment 
request . 

7. A system in accordance with claim 6, whereby 
30 the prepay card (C) forming the payment settlement 
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message is able to insert into said message proof that 
the requested amount has been debited from the card. 

8. A system in accordance with claim 6, whereby 
5 the prepay card (C) is able to build up a file 

containing the settled requests and corresponding 
amounts, and whereby the payment settlement message is 
only sent with its digital signature once this file has 
been updated. 

10 

9. A system in accordance with claim 8, whereby 
the prepay card (C) can be topped up, and whereby the 
file it contains is first transferred to the payment 
server (SP) during the topping-up process, for 

15 transferring funds to the software editors. 

10. A system in accordance with claim 6, whereby 
the prepay card (C) is of the "electronic wallet" type. 

20 11. A system in accordance with claim 5, whereby 

the card (C) is of the post-pay type. 

12. A system in accordance with claim 11, whereby 
the post-pay card (C) is able to build up a file 
25 containing the settled requests and corresponding 
amounts, and whereby the payment settlement message is 
only sent with its digital signature once this file has 
been updated. 
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13. A system in accordance with claim 12, whereby 
the card's file is transferred to the payment server 
(SP) for transferring funds to the software editors. 

14. A payment module (W) for a payment system for 
software program use, the characteristics of which are 
that is made up of the following: 

• the means of processing a first message (1) , 
notably containing the identity of a software 
editor (E) , software use offer parameters and a 
digital signature for at least part of said 
software use offer; 

• the means of sending this message (la) to a user 
(U) ; 

• the means of receiving an acceptance (lb) from 
said software program user (U) ; 

• the means of composing a second message (2) 
requesting payment, notably containing the 
identity of the user (U) and of the software 
editor (E) together with proof that the user (U) 
accepts the offer; 

• the means of receiving and processing a third 
message (3) containing a digital signature 
constituting proof of payment. 

15. A means of message and payment processing (SP) 
for a payment system for software program use, the 
characteristics of which are that is made up of the 
following : 

• the means of receiving a payment request message 
from a payment module (W) , in which said message 
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notably contains the identity of a user (U) and of 
a software editor (E) together with proof that the 
user (U) accepts the software use offer made to 
him/her; 

the means of checking that proof; 

the means of recording the payment request with at 
least the identity of the user (U) and of the 
software editor (E) , the amount to be paid and the 
means of crediting the software editor (E) with 
said amount; 

the means of also composing a payment settlement 
message (3) , notably containing the identity of 
the means of processing and a digital signature 
constituting proof of payment; 

the means of sending said message (3) to a payment 
module (W) . 



16. A means of message and payment processing (SP) 
for a payment system for software use, the 

20 characteristics of which are that it includes secure 
means comprising a smart card reader (LC) with a smart 
card (C) containing the identity of a software user, 
whereby the card reader and card are able to receive a 
message containing proof that the user has accepted a 

25 software use offer, check said proof, record a payment 
request and compose a payment settlement message (3) 
containing proof of payment. 

17. A means of message and payment processing (SP) 
30 in accordance with claim 16, whereby the card (C) is of 

the prepay type and contains a balance and whereby the 
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card is able to debit said balance with the request 
amount at each payment request. 

18. A means of message and payment processing (SP) 
in accordance with claim 17, whereby the prepay card 
(C) forming the payment settlement message is able to 
insert into said message proof that the requested 
amount has been debited from the card. 

19. A means of message and payment processing (SP) 
in accordance with claim 17, whereby the prepay card 
(C) is able to build up a file containing the settled 
requests together with the corresponding amounts, and 
whereby the payment settlement message is only sent 
with its digital signature once this file has been 
updated. 

20. A means of message and payment processing (SP) 
in accordance with claim 17, whereby the prepay card 
(C) can be topped up, and whereby the file it contains 
can be transferred during the topping-up process. 

21. A means of message and payment processing (SP) 
in accordance with claim 17, whereby the prepay card 
(C) is of the "electronic wallet" type. 

22. A means of message and payment processing (SP) 
in accordance with claim 16, whereby the card (C) is of 
the post-pay type. 
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WE (I) the undersigned inventor(s), hereby declare(s) that : 

My residence, post office address and citizenship are as stated below next to my name, 

We (I) believe that we are (I am) the original, first, and joint (sole) inventor(s) of the subject matter which is claimed and 
for which a patent is sought on the invention entitled 

"PAYMENT SYSTEM FOR SOFTWARE PROGRAM USE"^ 
- the specification of which 



□ is attached hereto. 
I I was filed on 

as Application Serial No. 

and amended on 
1X1 was filed as PCT international application 

Number PCT/FR00/01023 ^ 

on April 19, 2000 ^ 

and was amended under PCT Article 19 

on 



We (I) hereby state that we (I) have reviewed and understand the contents of the above-identified specification, including 
the claims, as amended by any amendment referred to above. 

We (J) acknowledge the duty to disclose information known to be material to the patentability of this application as defined 
in Section 1.56 of Title 37 Code of Federal Regulations. 

We (I) hereby claim foreign priority benefits under 35 U.S.C. § 119 (a)-(d) or § 365 (b) of any foreign application(s) for 
patent or inventor's certificate, or § 365 (a) of any PCT International application which designated at least one country other 
than the United States, listed below and have also identified below, by checking the box, any foreign application for patent or 
inventor's certificate, or PCT International application having a filing date before that of the application on which priority is 
claimed. Prior Foreign Application (s) 



Application No. 



Country 



Day/month/Year 



Priority 
Claimed 



99 04963 ✓ 



FRANCE 



20 APRIL 1999 



^ YES 

□ YES 

□ yes 

□ yes 



□ no 

□ no 

□ no 

□ no 
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We (I) hereby claim the benefit under Title 35, United States Code, § 1 19 (e) of any United States provisional 
applieation(s) listed below. 



(Application Number) 



(Filing Date) 



(Application Number) 



(Filing Date) 



We (I) hereby claim the benefit under 35 U.S.C. §120 of any United States application(s), or § 365(c) of any PCT 
International application designating the United States, listed below and, insofar as the subject matter of each of the claims of 
this application is not disclosed in the prior United States or PCT International application in the manner provided by the first 
paragraph of 35 U.S.C. § 112, 1 acknowledge the duty to disclose information which is material to patentability as defined in 
37 CFR § 1.56 which became available between the filing date of prior application and the national or PCT International filing 
date of this application. 



Application Serial No. 



Filing Date 



Status (pending, patented, 
abandoned) 



y I And we (1) hereby appoint : Norman F. Obion, Registration Njmih£r_24^J^-Marvin J. Spivak, Registration Nuiober^ 
fej?4 T 9L3 : C, Irvin McClelland, Registration Number. 21.124: G regory J. Maier, Registration N umber 25-5.99:. Arthur I. 
liNeustadt, Registration Number 24,854; R ichard D. Kelly, Registration Njm2bex_2J^15i^ James D. Hamilton, Registration 
t 'Number 28.42 LJ Eckhard H. Kuesters, Registration Number 28.870; R obert T. Pous, Registration Number 29,099; , Charles 
s L. Gholz, Registration NnnThj-r_?6,395; . William E. Beaumont, Registration Number 30.996; J ^an-Paul Lavalleye, 
i Registration Number 31.451: S tephen G. Baxter, Registration Number 32.884; R ichard L. Treanor, Registration Number 
; ;36.379; Ste ven P. Weihrouch, Registration Number 32,829; John T. Goolkasian, Registration N umber 26,142; Richard L. 
|jChinn, Registration Number 34.305; Ste ven E. Lipman, Registration N umber 30.01 1; Ca rl E. SchBer, Registration Number 
j a 34 3 426^James J. Kulbaski, Registration N umber 34,648; R ichard A. Neifeld, Registration Number 35,299; J. Derek Mason, 
Registration N umber 35,270;^ Surinder Sachar, Registration N^unate-34 ? 433i Christina M. Gadiano, Registration Number 
l2Jj §2S: J effrey B. Mclntyre, Registration Number 36 867;_ WilHam T. Enos, Registration Number 33.128: J Vlichael E. 
HWcKabe Jr., Registration Number 37, 1 82, . Bradley D. Lytle, Registration Number 40,073 an d Michael R. Casey 
Registration Number 40.294 ; our (my) attorneys, with full powers of substitution and revocation, to prosecute this 
application and to transact all business in the Patent Office connected therewith; and we (I) hereby request that all 
correspondence regarding this application be sent to the firm of OBLON. .. SPIVAK. McCLELLAN EL- MAIER & 
J jEUSTADT . P.C., whose post Office Address is : Fourth Floor, 1755 Jefferson Davis Highway . Arlington. Vjrgjriia 
'_22202_ ' " ' ' 

We (I) declare that all statements made herein of our (my) own knowledge are true and that all statements made on 
information and belief are believed to be true ; and further that these statements were made with the knowledge that willful 
false statements and the like so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the 
United States Code and that such wilful false statements may jeopardise the validity of the application or any patent issuing 
thereon. 
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